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Sir: 



Radhika Aggarwal, William H. Krebs, Elizabeth A. Schreiber and David Styles, the 
applicants in the above-identified patent application, declare as follows: 

We are the sole inventors of the subject invention claimed in the above-identified United 
States Patent Application Serial No. 10/041,141, filed January 3, 2002. 

We have read and understood the office action mailed September 17, 2004 and the 
individual references cited therein, and we make this declaration in support of the patentability of 
the claims of the United States Patent Application Serial No. 10/041,141. 



Application No. 1 0/04 1,141 
Filed: 1/3/2002 
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This declaration made under 37 CFR § 1.131 is made in response to the rejections of the 
claims in the foresaid office action under 35 USC § 103(a) based upon United States Patent 
Application Publication No. US 2003/0105884 to Upton et al. 

Prior to October 2001 , the date of filing of the provisional patent application to which 
Upton claims priority, we conceived the above-identified and claimed invention. As factual 
evidence of this, the following facts are entered with supporting documentation. 

1 . Sometime prior to October 2001 , the applicants conceived of an in-line error highlighting 
system, method and apparatus, hereinafter the "Invention". 

2. The Invention included an in-line error highlighting method having the following steps: 

a. detecting in a form-based submit, at least one validation error based upon a value 
provided through an input-element in a markup specified form; 

b. inserting a row in the markup specified form in a position which is proximate to 
the input-element, said row having a background color which differs from other 
colors which are visible in proximity to the inserted row; 

c. selecting error text corresponding to the validation error and inserting the 
selected error text in the row; 

d. further inserting an anchor tag in the markup specified form in a position which is 
proximate to the input-element; and, 

e. serving the markup specified form in a response to the form-based submit, the 
response referencing the anchor tag. 

3. A disclosure document entitled "RSW8-2000-0307" describing an embodiment of the 
Invention (the "Disclosure") had been submitted to an attorney representing my employer, IBM 
Corporation, on December 20, 2000. A copy of the Disclosure, having redacted portions, has 
been attached hereto as Exhibit A. 

4. At the time of submitting the Disclosure an experimental prototype of the Invention had 
been created and work had begun in producing a production version of the Invention. 

5. On June 14, 2001 , work commenced on a draft document which ultimately became United 
States Patent Application S/N 10/041,141 (the "Patent Application") and on October 29, 2001, 
we reviewed a final draft of the Patent Application. 

6. On January 3, 2002, my employer, IBM Corporation, filed the Patent Application in the 
United States Patent Office. 

It is respectfully submitted that the present patent application claims an invention which 
was conceived prior to October 2001, and reduced to practice with due diligence from before 
December 20, 2000 leading up to January 2002, the filing date of the present patent application. 
Accordingly, the Upton reference should be removed as a reference under 35 U.S.C. § 103(a). 
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I further declare that all statements made herein or my own knowledge are true and that all 
statements made on information and belief are believed to be true and further that these 
statements are made with the knowledge that willful false statements and the like so made arc 
punishable by fine or imprisonment or both under Section 1001 of Title 18 of the United States 
Code and that such willful false statements may jeopardize the validity of the application or any 
patent issued thereon. y 
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Exhibit A 



Dis^M RSW8-2000-0307 

Prepared for and/or by an IBM Attorney - IBM Confidential 

Created By: Radhika Aggarwal Created On: 1 2/1 9/2000 02:39:58 PM 

Last Modified By: Linda Dupont Last Modified On: 12/26/2000 08:48:47 AM 



Required fields are marked with the asterisk (*) and must be filled in to complete the form . 



ItTitle of disclosure (in 








Inline Error Highlighting for HTML 3.2 Clients 






Summary 








Status 


Under Evaluation 






Processing Location 


RSW 






Functional Area 


Attorney/Patent 
Professional 


Gerald R Woods/Raleigh/IBM 






IDT Team 






i 


; Submitted Date 


1 2/20/2000 02:1 7:1 7 PM EST 






| Owning 
! Division 


jLab 


Technology Code 


PVT Score 









Inventors with Lotus Notes IDs 

Inventors: Radhika Aggarwal/Ratetgh/JBM, David Styles/Raleigh/IBM, Beth Schreiber/Raleigh/IBM, William Krebs/Raleigh/IBM 



Wentor Naffiej^ MMidrM^ 


Inventor ; 
^vS^m^^m:. Oiv/Pep 


Inventor 


> Aggarwal, Radhika 






Styles, David 






Schreiber, Elizabeth A. (Beth) 






Krebs, William H. (Bill) 







> denotes primary contact 



Inventors without Lotus Notes IDs 

IDT Selection 
*Main Idea 

1. Describe your invention, stating the problem solved (if appropriate), and indicating the advantages of 
using the invention. 



RSW8-2000-0307 Inline Error High! i„ . HTML 3.2 Clients - continued 



Needed to find a way to display dynamic error messages using only HTML 3.2. The error messages had 
to be displayed near the object with the invalid data. The messages also had to be created dynamically 
according to the data provided by the user. 

2. How does the invention solve the problem or achieve an advantage,(a description of "the invention", 
including figures inline as appropriate)? 

The invention allows us to create dynamic error messages for HTML 3.2 Clients. When developing the 
solution, the following had to be taken into consideration: 

• Presentation of the error message 

• Handle various error messages for one object 

• Visibility of the error message 

Presentation 

The presentation and placement of the error message was important part of the solution. The error 
message had to be placed where the user could understand which object was invalid. Generally, error 
messages are displayed in an "alert box" or the top of the page. We could not use an "alert box" because 
that required the use of JavaScript and our requirement was to use HTML 32 only. Using HTML 3.2 we 
could have placed our messages at the top of the page, however we wanted a more appropriate place for 
the error message. For example, if the error message and invalid object were really far apart on the page 
then the user may have scroll up and down to see the error message and the invalid object. We decided 
to place the error message right under the invalid object. By having the error message near the object, 
creates an environment where the object and error message is visible together. In order to f^tce the error 
message beneath the object, we would reload the page and add an extra row underneath the object. This 
new row would contain the error message. We also place an image next to object to indicate that the 
object is invalid. 

Another concern was to ensure that the displayed message was distinctive from the rest of the text on the 
page. If the error message does not have a different look from the regular text, then the user may over>. 
look the error message. To achieve that effect the row, that was added in order to hold the error message, 
was given a background color. Normally, the text the surrounding an object on the page as a background 
color of white. By giving the error message a different background it made the message text look visually 
different from the regular text on the page. 

A T e st Input Numb er 



'A Test Input Number (turn 10, mag 9'?/ is too small. It has tobg at least 10. 



Error Messages 

The back-end application can have various kinds of error messages for just one object. For example, if 
the page had an input field that only excepted a number between 10 and 99. 

A Test Input Number (min 10, max 99) 

E° □ 

Depending an the back-end application, this input field could have different kinds of error messages, such 
as: 

• The data entered is not a number. 

• The data entered is too small. 

• The data entered is too big. 
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RSW8-2000-0307 Inline Error Higt \x\± HTML 3.2 Clients - continued 



As we evaluate the data from the user the back-end application will indicate that this object has an error 
message. Once we receive the indication we will store the message so we know which message will be 
displayed. Then we insert the message into the row that was added. Thus the page will load with the 
message that was decided by the back-end application. 



Visibility 

Once we displayed the error message, another concern was that would the user always immediately know 
that there is an invalid object. For example, if the invalid object was towards the bottom of the page so 
then when the page reloads the invalid object may not be visible. If the invalid field is not visible 
immediately and since we do not place a message at the top of page indicating something is incorrect, 
then the user may be confused about why the page reloaded. Thus, we wanted the page to reload with the 
invalid object in the range of the window. To achieve this effect, we used the concept of jumping to a spot 
on the page by using the anchor tag and in the URL. If an object was marked invalid we would add an 
anchor, whose name matched the word in the URL following "#", at the beginning of the object. By placing 
"rt at the beginning of the object, ensured that both the object and the error message would be visible, 
since error message is beneath the object. 

Another concern with visibility was what if the page had multiple viewing areas (like a wizard or had tabs). 
Then the error could be on a different view then the one currently displayed. Thus, the user can not see 
the error message unless he/she manually went through each tab looking for it. To resolve this concern, 
we would set the view with the error field to visible and use the a #* and anchor tag technique. Our 
technique allows us to make any error message visible across any number of views. 

3. If the same advantage or problem has been identified by others (inside/outside IBM), how have those 
others solved it and does your solution differ and why is it better? 

Many web pages support the display of error messages, however their approach does not meet our 
requirements. The two most common ways that error messages are handled are by displaying a "alert 
box" or placing the error messages at the top of the page. We could not use "alert boxes" because they 
are part of JavaScript and not HTML 3.2. WE could display the message at the top of page using only 
HTML 3.2, however that is not the visual effect we wanted to achieve. 

4. If the invention is implemented in a product or prototype, include technical details, purpose, disclosure 
details to others and the date of that implementation. 

The invention is implemented in the Unity CSA Web-Served solution, which is currently under 
development. This product is a component in the Common System Administration tooling being 
developed to bring a more cohesive end-user experience and lower development cost to all IBM 
Administrative consoles. 

Products using the Unity CSA console tooling will develop all their panels in an XML vocabulary known as 
AUIML. Unity CSA provides a Visual Builder to build the AUIML panels, a Java Swing Tenderer to render 
the panels in Java on an installed client platform, an HTML 3.2 renderer to render the panels in HTML on * 
an HTML 3.2 compliant browser, a servlet to serve Unity CSA application over the web, a Console 
application, and APIs to interact with the Console and the panels. This tooling enables developers to 
create applications that run in multiple environments without the need to re-write the GUI. In the future, 
additional Tenderers will be provided to further leverage this technology. 



(Form Revised 12/17/97) 
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